A web application, also called a web app, is an application relying on web technologies. Typically, such an application is developed in the HyperText Markup Language (HTML), the Cascading Style Sheets (CSS) language, or the JavaScript language. A web application is generally designated through a Uniform Resource Locator (URL) which indicates a resource, for example an application. Therefore, what is sometimes referred to as a “web page” can also be seen as a web application. A web application can also be a packaged application that may be installed on a device. In such a case, the application is stored persistently on the device.
In the context of the invention, it is considered that a web application is typically executed by a Web Runtime Environment (WRE), for example Mozilla's Firefox OS or a web browser, enabling web applications loaded and run in the web runtime environment to cooperate.
FIG. 1, comprising FIGS. 1a and 1b, illustrates two examples of web runtime environments.
As illustrated in FIG. 1a, a web runtime environment can be a software component 100 relying on an operating system 105 to run web applications 110. A web runtime environment typically consists of one or several software modules, for example generic modules and specific modules, among which a web runtime controller, which may comprise sub-modules. Web browsers like Mozilla Firefox, Google Chrome and Microsoft Internet Explorer, are examples of such a web runtime environment (Google, Chrome, Microsoft, and Internet Explorer are trademarks).
Alternatively, as illustrated in FIG. 1b, a web runtime environment 100′ can be integrated into an operating system 105′ to run web applications 110′. In such a case, the whole operating system is based on web technologies. Examples of such a web runtime environment are Google Chrome OS and Mozilla Firefox OS.
A script module comprises a set of code instructions that can be executed by a web runtime environment. JavaScript™ is a common language for writing script modules.
The HTML enables web applications to embed script modules through the “script” tag. When a web runtime environment processes such a tag in the HTML code of a web application, it can determine some code that it should load and execute so that the corresponding web application can use it. The code may be directly included within the “script” tag. The code may also be indicated through a reference to a resource that can be determined from an attribute of the “script” tag, typically the “src” attribute.
Alternatively, a web runtime environment may also execute a script module even if not referred to by a web application. In particular, this is the case of web browser extensions. Such extensions complement web browsers with additional features. Such additional features may or may not be made available to web applications. In case they are made available, web applications can use such features (e.g. a specific Application Programming Interface “API”) as if it were directly provided by the web runtime environment.
This is therefore a specific way for a web runtime environment to provide a certain features to web applications. Consequently, in the remainder of this document, when it is the case that a web runtime environment provides certain features to a web application, it is considered that one of the way for the web runtime environment to do so consists in relying on a script module. Another way of doing this consists in having the feature to be implemented in the source code of the web runtime environment.
In the following description, different components may interact through interfaces. In particular, a web application or a script module may interact with a web runtime environment through an interface. Similarly, a web runtime or a script module may interact with a network service through an interface.
An interface may provide a set of functions implemented by a given component and that can be called by another component. For instance, a web runtime environment may call some functions of such an interface implemented by a driver application. In some cases, the interface may also define events that can be triggered by the other component and caught by the given component. The catching of such an event enables the given component to determine a process to be performed. For instance, a web runtime environment may trigger a “start” event of a driver application so that the driver application starts the processing of a task.
An interface may also provide a communication channel through which messages can be exchanged between two components. In such a case, it is considered that the kind of messages that can be exchanged is a part of the interface. A specific kind of message enables the first component (resp. the second component) to request the second component (resp. the first component) to perform a corresponding processing. If both components do not agree on the meaning of messages, no communication is possible. In a specific implementation, messages may be obtained through an event system (as described with regard to the first type of interface). In this second case, the means associated with the communication channel do not depend on the type of the interface (such means are generic and can be used for any type of interface, contrary to the set of messages which are specific and makes the interface distinct from other interfaces).
A network service is a service made accessible through a network. Examples of such services are remote media display services which provide the service of displaying media on a remote screen or network printing services which provide the service of printing a document thanks to a printer connected to a network.
Such services generally implement specific application programming interfaces (API) enabling applications to interact with them. Implemented APIs depend on the type of service provided. For the sake of illustration, the Universal Plug and Play (UPnP) protocol defines a number of different types of services.
Prior to interacting with a network service, an application has to discover which services can be accessed. This can be done thanks to discovery protocols, such as multicast Domain Name System (mDNS) protocol. A discovery process basically consists in sending a request for services on a network and waiting for responses. Each response typically provides information about a corresponding service by providing, for example, a URL to a configuration file describing the considered service.
Alternatively, each of the services periodically advertises itself to all the devices connected to a considered network, without requiring any discovery request.
It is to be noted that network services are generally implemented by devices which are different from the ones which make use of them. Accordingly, these services are often called remote services. Nevertheless, an application running on a given device can access a service through a network interface even though that service is hosted in the same device.
There exist APIs, in particular JavaScript APIs, which provide web applications with interaction capabilities so that those web applications can address requests directed to services that are remote from the web runtime environment (or web browser) in which they are executed. For the sake of illustration, a web application can request the printing of specific data, for example using the known window.print( ) function, or can request the displaying on a remote display of the data pointed to by a URL, for example using the Presentation API which is an API currently standardized by the World Wide Web Consortium (W3C).
In such cases, the requesting web application does not request a specific service or type of service and does not know exactly how to interact with the remote service. Interactions between the web application and a specific service are handled by an API which provides high-level control to the web application, enabling the latter to interact with a service of a predetermined type.
Discovering available services of a predetermined type is carried out by the web runtime environment which interacts at a low-level with a selected remote service. Still for the sake of illustration, a web runtime environment can use a page description format, when processing printing requests, to obtain printable data from provided data, and a communication protocol such as Internet Printing Protocol (IPP) in order to interact with an IPP printer. According to another example, the web runtime environment can use a protocol such as Miracast for remote displaying of data (Miracast is a trademark).
However, since web runtime environments interact with an increasing number of devices and services, more and more technologies have to be integrated in web runtime environments so that they can interact with these devices and services.
As a consequence, there is a need for implementing such technologies efficiently.